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ABSTRACT 


Psma meciod OL controlling the rapidly rising costs and 
schedule delays plaguing software systems, Department of 
Defense (DOD) has implemented the concept of life cycle 
management for automated information systems (AIS). This 
thesis analyses the DOD life cycle management directives 
through the development of the TRIDENT Submarine Logistics 
Data System AIS. Specifically, it examines DOD software life 
cycle phasing and studies the cost and schedule variance 
guidelines established by the life cycle management directives. 
This thesis points out an apparant need for clarifying the 
DOD budget guidelines and a refining of the life cycle 
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foe LN RODUCT ION 


A. COMPUTER SOFTWARE DEVELOPMENT PROBLEMS 

Computer programs - generally called software packages - 
are instructions that tell computer systems what actions to 
take. As computer systems have become increasingly more 
sophisticated, attempts have been made to apply these systems 
to solving progressively more complex and intricate problems. 
Mismatches between the desired level of performance and the 
technical abilities to attain these levels of performance 
have become evident with the increasing complexity of software 
needs. The problems of writing and maintaining complex 
computer programs is causing computer software costs to out- 
strip hardware costs [Ref. 1]. A General Accounting Office 
(GAO) reports notes that by the mid-1980s over 90 percent of 
the cost of a computer system will be software costs [Ref. 2]. 
Figure 1 shows this relationship between hardware and soft- 
ware costs [Ref. 3]. 

The growing number of software project cost overruns, 
schedule slippages, user dissatisfaction and verformance 
degradation in the recent past have created a growing apprecia- 
tion for better management and control of personnel and dollar 
resources identified for these projects. A recent GAO survey 


indicated that government software development projects suffer 
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Figure lL. Hardware/Software Cost Trends 
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from these same problems [Ref. 4]. Figures 2, 3, and 4 show 
some of the survey questions and the responses to those 


questions. 


B. DOD MANAGEMENT OF COMPUTER SOFTWARE PROJECTS 

The Department of Defense (DOD) currently spends millions 
of dollars each year to develop, procure, and operate auto- 
mated information systems (AIS). As defined by DOD Instruction 
7920.1 entitled "Life Cycle Management of Automated Information 
Systems (AIS)", an AIS is: 

aes a COllection of functional users and ADP personnel, 
procedures, and equipment (including ADPE) which is 
designed, built, operated, and maintained to collect, 
read, process, store, retrieve, and display information." 

To be more specific, an AIS is a computer system, the 
management of which not only includes all the computer programs 
within the system, but also the computer hardware on which the 
software system will run. 

In an effort to more efficiently control and manage its 
limited resources, DOD implemented life-cycle management 
procedures on all AIS with the exception of command and control 
ana communication AIS with the promulgation of DOD Instruction 
7920.1 in October, 1978. A new review and decision process 
for AIS was established by DOD Instruction 7920.2 entitled 
"Major Automated Information Systems Approval Process" also in 
October, 1978. Secretary of the Navy (SECNAV) Instruction 


5231.1A entitled "Life Cycle Management of Automated Information 


Systems within the Department of the Navy" promulgated the 
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Figure 4. The Delivered Software Must Be 
Corrected or Modified 
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policies and assigned the responsibilities for overall life- 
cycle management within the Department of the Navy in November, 
79. 

These directives and instructions show a major change in 
the philosophy of managing computer software projects in the 
military. Prior to life-cycle management, DOD Directive 
4105.55 entitled "Selection and Acquisition of Automated Data 
Processing Resources" and DOD Instruction 5100.40 entitled 
"Responsibility for the Administration of the DOD Automatic 
Data Processing Program" were the primary software development 
documents and concerned controlling the cost of acquiring 
software systems. These instructions asked the following 
questions: (1) Where are we? (2) Where do we want to be? 

(3) What specific steps are we going to take? (4) Who is 
responsible? (5) What resources are required?, and (6) Is 

the effort worth-while? [Ref. 5]. Still, the systems developed 
under them tended to cost much more than the original estimates 
and were delivered much later than expected. 

Life cycle management considers the acquisition cost of 
the project plus operation, maintenance, and any other cost of 
an ALIS project from program initiation throughout a stated 
life time or period of service for the project. Life cycle 
management is heavily weighted toward the developmental phases 
of the AIS. Decision points or milestones are interjected at 
Specific times during the development process where the pro- 


ject is reviewed for accuracy in satisfying customer requirements 


ES 





and compliance to cost and schedule constraints. Life cycle 
management stresses planning and is one of the primary methods 
of attempting to control spiralling software development costs 
and project delays in DOD. 

SpePparticular importance to the transition to life cycle 
management is the requirement by DOD Instruction 7920.2 to 
create a Systems Decision Paper (SDP) for each major new AIS 
or major modification to an existing AIS and the maintenance 
of this document throughout the life of the AIS. The SDP will 
be the principal document for recording all the essential 
information on an AIS such as mission need, alternatives, 
cost/benefit analysis, budgets, future fiscal year funding 
needs, management plans, development plans, and test and 
evaluation plans and will be used by the Office of the 
Secretary of Defense (OSD) and DOD to support the decision 


making process regarding the AIS. 


C. PROBLEMS FACING TRIDENT SUBMARINE LDS 

The TRIDENT Submarine Logistics Data System (LDS) is a 
technically complex, totally integrated series of software 
programs that are being developed to support the operation of 
the TRIDENT submarine fleet. When implemented, the TRIDENT 
LDS will be the heart of a comprehensive coordinated logistics 
support network whose functioning will help the TRIDENT 


submarines attain stringent operational requirements. 
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In 1980, when the TRIDENT LDS was required to implement Life 
Cycle Management and the SDP reporting process, it had been 
under development for eight years, was approximately $19,000,000 
over cost, and was only 40 percent complete. 

The change to life cycle management created a number of 
problems for the various managers within the TRIDENT LSD. Of 
particular interest to this thesis are two questions which were 
raised regarding guidelines and constraints under which budgets 
were to be formulated and actual costs accumulated: 

1. The separation of TRIDENT LDS costs into the 

categories of Design, Maintenance, and Management 

costs - Previous to implementing life cycle management, 

all costs attributable to the TRIDENT LDS were aggregated 

together into a single category or cost element within 

the TRIDENT Submarine Project. The categories of 

Design, Maintenance, and Management stemmed primarily 

from attempting to define the acquisition/development 

approval authority thresholds for the TRIDENT LDS and 

those functions which constituted development costs and 

maintenance costs. 

2. Application of the budgeting cost and schedule 

Variances established by the life cycle management 

instructions and directives - Estimating the costs and 

time required to complete software development projects 

tends to be ambiguous and difficult. The precariousness 


of these estimates escalates dramatically as the timing, 


a 





technology, and complexity demanded from the projects 
increases. The TRIDENT LDS AIS does not appear to fit 
into the developmental mold described in the life cycle 
Management instructions and the cost and time constraints 
seem to impose an artificially firm budget and schedule 
to portions of the project that are to be developed 
three, four, or more years in the future and whose 


Functional capabilities have not been determined. 


PeeteetolS OBJECTIVES AND METHODOLOGY 

This thesis is aimed at investigating software development 
processes in order to provide a definition through which 
TRIDENT LDS functions and costs may be designated into the 
appropriate Design, Maintenance, or Management category and 
examining budgeting and budget guidelines so that application 
of the cost and schedule variances may be determined. 

Additionally, a comparison is made between the manner in 
which the TRIDENT LDS project is being developed, guidelines 
provided by DOD, and ‘theoretical’ development phases for the 
mmepmose of highlighting any procedural or conceptual differ- 
ences which could have been bearing on budgeting and recommend- 
ing changes to the vrocess. 

In conducting the investigation a search of journals, 
periodicals, books, and government documents was accomplished. 
This was done to develop the author's level of knowledge from 


which evaluation of the TRIDENT LDS could be made. Further, 
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field trips were made to the TRIDENT LDS ADP Manager Fleet 
Material Support Office (FMSO 96T), Mechanicsburg, PA so that 
current methodology used for budgeting and software develop- 
ment in the TRIDENT LDS could be studied. It is on these 
research efforts and the information obtained that the weak- 
nesses are highlighted, conclusions drawn, and recommendations 


based. 


PeORGANIZATION OF THESIS 

Chapter II discusses the development of the TRIDENT sub- 
marine and the basic concept of Integrated Logistic Support 
(ILS) for it, describes the TRIDENT LDS program, and outlines 
the TRIDENT LDS Systems Decision Paper (SDP). Chapter III 
compares software life cycle phases as described in manage- 
ment information system books and industrial situations with 
the DOD life cycle phases and the development of the TRIDENT 
LDS. Differences are noted and a method for phasing software 
development presented. Chapter IV addresses budget processes, 
discusses the division of software development function and 
costs into Design, Maintenance, and Management categories, 
and projects some interpretations in applying the variance 
constraints established by DOD Directive 7920.1 and SECNAV 
Mietermuction 5231.1A. Finally, Chapter V offers a summary, 


conclusions, and recommendations for areas of future study. 


ILS, 





Ii. TRIDENT SUBMARINE LOGISTIC SUPPORT 


A. DEVELOPMENT OF THE TRIDENT SUBMARINE LOGISTICS CONCEPT 

The TRIDENT submarines scheduled for deployment during the 
1980s are intended to become the primary sea based weapons 
system in the United States strategic deterrent forces 
[Ref. 6]. Currently there are seven TRIDENT submarines under 
Semmebact Lor construction, one TRIDENT contract scheduled for 
approval during fiscal year 1981, and procurement of an 
additional eighteen TRIDENTs identified in future fiscal year 
budget submissions. At present, the goal is to have two 
squadrons of TRIDENT submarines each with ten operational 
Ships. Although the projected number of TRIDENT submarines 
is Significantly less than the size of the current United 
States Polaris/Poseidon fleet, a decision was made that the 
TRIDENT fleet would have a higher on-line availability than 
the Polaris/Poseidon fleet [Ref. 6]. In order to achieve 
higher levels of on-line availability, the on-line capability 
of each TRIDENT submarine had to be increased. Chief of Naval 
Operation identifies an operating cycle for TRIDENT submarines 
which requires longer patrol periods, shorter refit periods, 
a shorter and less frequent shipyard overhaul periods. TRIDENT 
submarines are to operate on a 70-day patrol/18-day refit cycle 
for a period of not less than nine years between scheduled 


12 month shipyard overhaul periods. 
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The requirement for increasing on-line availability signif- 
icantly affected the development of the overall TRIDENT project 
in a number of areas: 

1. The design of the submarine was affected by attempting 
to increase equipment and component maintenance and reliability 
Factors and by increasing accessibility to equipment in order 
to facilitate equipment repair or replacement. 

2. A maintenance strategy was developed which called for 
the planning and scheduling of all maintenance actions at all 
levels for all patrols and refits from initial deployment of 
each ship through scheduled shipyard overhauls. This mainten- 
ance program includes all maintenance to be accomploshed on 
board each ship each patrol by ship's force personnel; coordi- 
nation of the Intermediate Maintenance Activity (IMA) for 
maintenance it will verform each refit cycle; augmentation of 
IMA maintenance by periodic planned replacement of equipment 
prior to their expected failure time; and coordination of 
depot level maintenance for repair of items removed from the 
Submarines which require depot level maintenance action. 

3. All logistic requirements — repair parts, spares, 
tools, technical documentation, industrial facilities, etc. — 
are to be planned and controlled. 

4. All data regarding equipment configuration and mainten- 
ance practices is to be continuously accumulated and updated 
in order to keep logistic support current with the equipment 


sentfiguration. 
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Coupling these requirements to the requirement for a 
Peetstic information capability for the TRIDENT submarine as 
identified in OPNAV Instruction 4000.82 entitled "Logistics 
Support of the TRIDENT System" generated the need for a high 
intensity, meticulously managed Integrated Logistics Support 
(ILS) program. A program with this type of logistic informa- 
tion capability is not currently available to the Navy 


[Ref. 7]. 


B. INTEGRATED LOGISTICS SUPPORT (ILS) 

ILS as described by Chief of Naval Material (NAVMAT) 
Instruction 4000.20B entitled "Integrated Logistics Support 
(ILS) Planning Policy" and DOD Directive 4100.35 entitled 
"Integrated logistics support planning guide for DOD systems 
and equipment" is: 

"A composite of all the support considerations necessary 
to assure the effective and economical support of systems/ 
equipments for their life cycle. It is an integral part 
of system/equipment acquisition and operation and is 
characterized by harmony and coherence among all logistic 
elements." 

ILS is based on detailed analysis of all interaction and 
interdependency of equipment/component/system hardware design, 
development and performance specifications, and known or 
projected support requirements. The ILS process also identifies 
the resources necessary to support any operation and mainten- 
ance functions and strives for reducing the support burden 


Merdced On Operating forces [Ref. 8]. The principai elements 


related to the ILS concept are listed in Appendix A. 
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The ILS concept is extremely important not only because 
it aids earlier identification of life-cycle costs and can 
help reduce total project costs but also because without 
adequate support, equipment and systems may not be able to 
meet expected operational capabilities. Systems which cannot 
operate satisfactorily in prescribed environments for a speci- 
fied length of time and, when failed, cannot be restored to 
service within a specified length of time will not satisfy 
operational requirements [Ref. 9]. Additionally, the avail- 
ability of items needed for system operation and maintenance 
Such as test equipment, trained personnel, and repair parts 
will impact satisfying operational requirements. 

An ILS plan for the TRIDENT Submarine System has been 
promulgated by the TRIDENT Systems Project Manager (Chief of 
Naval Material PM-2). This plan assigns the responsibility 
for planning, coordinating, developing, and integrating all 
logistic elements required to support TRIDENT submarines from 
acquisition through operation into a TRIDENT Logistic Support 
System. This Logistic Support System includes [Ref. 10]: 

ee erertt Coacility and a training facility located at 
Bangor, Washington, which are dedicated to providing mainten- 
ance, refit services, supply support, and crew training for 
TRIDENT submarines. 

Pee TREDENT Support Organization in Mechanicsburg, PA 
whose responsibility is to provide technical and management 


moport for TRIDENT logistic requirements. 
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3. Logistic Element Managers (LEMs) whose responsibility 
is to identify, acquire, and manage logistic resources applicable 
to their specific equipment. 

4. A TRIDENT logistic information system that can coordi- 
nate and perform all the logistic functions required for a 
complete ILS system. 

This logistics information system — the TRIDENT Logistics 


Data System (LDS) is discussed in the following section. 


@= TRIDENT LOGISTIC DATA SYSTEM (LDS) 

The TRIDENT LDS currently under development is a key 
element in implementing the total ILS concept for the TRIDENT 
Submarine System. The TRIDENT LDS is a shore based dedicated 
AIS having the objective: 

",.. to provide an integrated information system necessary 
to support the intensified level of maintenance and 
logistics support required for TRIDENT submarines to 
achieve their high level of operational availability 

Meet. 11j." 

Its development and degree of success will be important to 
other DOD activities and to the development of future ILS 
projects because the TRIDENT LDS is the first time that an 
attempt has been made to implement the ILS concept for an 
entire weapons system. Additionally, it is being developed 
in such a manner as to interface with other standard Navy 
information systems such as the Fitting Out Management Infor- 
Mation System (FOMIS), the Weapons System File (WSF), the 


Navy Maintenance Material Management (3M) System, and the 


Uniform Automated Data Processing System (UADPS) [Ref. 12]. 
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The TRIDENT LDS developed through three phases since its 
inception. Development began in 1972-1973 prior to preparation 
of detailed Requirements Statements (RS) describing user func- 
tions that had to be satisfied by the data system. Initially 
the TRIDENT LDS was conceived as a central computer system 
located at the TRIDENT Support Activity in Mechanicsburg, PA 
that was to be linked to remote terminals located at the TRIDENT 
Refit Facility (TRIREFFAC) in Bangor, WA. By the time the 
Formal RSs were created in 1975-1976, the centralized computer 
idea was changed and the decision made to provide computer 
capabilities at the TRIREFFAC in order to facilitate scheduling 
of maintenance action to be performed during the short, time- 
sensitive refit periods. Also during this period plans were 
developed which would resolve some incompatibilities that had 
emerged between operational data systems and allow them to 
interface with each other and with the TRIDENT LDS. The 
TRIDENT LDS began its third phase of development in 1977 when 
systems requirements were refined, software programming started, 
and hardware procured. 

During these three phases of development, an LDS project 
completion date of September 30, 1980 had been established. 

By December, 1978, a decision was reached that the TRIDENT LDS 
project would not achieve its scheduled completion date and 
that projected cost of the project would be in excess of the 
25 percent cost growth allowed by the Automated Data System 


Development Plan (ADS Plan). As required by the ADS Plan when 
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time and cost estimates can not be met within prescribed 
limits, a TRIDENT LDS project review was conducted and revised 
cost estimates and time schedules developed. These revisions 
were approved but along with the approval was the requirement 
to implement life-cycle management and the SDP process as set 
eemeen in DOD Directive 7920.1, DOD Instruction 7920.2, and 
SeenAyY Instruction 5231.1A. 

The TRIDENT LDS is organized into five major information 
areas which provide TRIDENT LDS users with data necessary to 
Seevrae logistic support within that functional area. A sixth 
LDS branch creates the operating environment needed in order to 
operate the programs on the LDS hardware. Figure 5 shows the 
TRIDENT LDS tree [Ref. 13] and Appendix B summarizes the 
functions within each major LDS branch. 

The development of the TRIDENT LDS has been segmented into 
five phases or revisions. Each revision represents a level of 
effort needed to implement a specific enhanced operational 
Capability to the TRIDENT Submarine System. It is to these 
revisions that budgeting and cost accumulation are to be 
directed. Figure 6 is a matrix that shows the interrelation- 
Ships between LDS revision numbers, the major system or branch, 
the SDP AIS milestone, and projected completion dates of each 
SDP milestone within a specific TRIDENT LDS revision [Ref. 14]. 
The SDP AIS milestones are explained in Chapter III. The 
‘Release' column on Figure 6 represents a major branch update/ 


Verification to ensure that the branch will continue to operate 
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Figure 6. TRIDENT LDS Milestone Status 
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correctly with another branch which may have been changed as 


the result of a TRIDENT LDS revision [Ref. 15]. 


Meee LREIDENT LDS SYSTEM DECISION PAPER (SDP) 

Bebeinstruction 7920.2 states that: 

"The successful management of an AIS requires that the 
combined and integrated efforts of functional, ADP, and 
telecommunications organization and personnel. The SDP 
process provides for appropriate policy level involvement 
in key decisions during the life cycle of each major AIS." 

An SDP 1s projected to be a living document in existence 
throughout the life cycle of an AIS. Once the Mission Element 
Needs Statement (MENS) describing a specific mission deficiency 
and justifying the need to seek alternate methods of solving 
the deficiency has been approved by the Secretary of Defense 
(for major AIS), an SDP is prepared by the AIS Project Manager 
for use in DOD and OSD decisions regarding continued develop- 
ment of the AIS. If approved by the OSD, the SDP is returned 
to the applicable DOD activity for further work on the AIS. 
Figure 7 shows the approval and management organization of the 
HRaDENT LDS [Ref. 16]. 

The SDP is based on the four specific AIS SDP milestones 
and related status and the five developmental phases for an 
AIS described in DOD Directive 7920.1. When all tasks required 
to progress from a previous milestone are completed, the SDP 
is updated and resubmitted to the OSD for review and approval 


to continue to the next phase of developing the AIS. During 


this OSD review process, any conflicts such as between 
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projected cost and schedule goals or guidance as given by the 
OSD and actual direction taken by the SDP is documented and 
the ADP endorsed to reflect the OSD recommendations and 
decitions. As endorsed, the SDP is returned to the applicable 
DOD activity and, if the SDP has been approved, development of 
the AIS continued. Because of the tremendous amount of work 
that had been accomplished on the TRIDENT LDS under the ADS 
Plan and the effort involved in transitioning to the SDP 
process, development of the TRIDENT LDS continues bu the formal 
SDP has yet to be approved by OSD. 

As required by DOD Instruction 7920.2, the TRIDENT SDP 
contains: 

1. The MENS and a user requirements summary identifying 
the basic user requirements to be satisfied by the TRIDENT LDS. 

Zee ine project plan including the description of the 
system, the plan by which the system will be managed and by 
whom, and the plan describing the manner and methodology of 
developing the system. 

Se) The acquisition strategy concerning TRIDENT LDS hard- 
ware, software, and supporting telecommunications requirements. 

fer LOgiSstics and training plan for the system. 

5. Resources requirements including a Cost/Benefit 
Analysis (CBA) of alternatives considered. 

6. A test and evaluation plan for conducting hardware 
and software tests, system effectiveness reviews, and 


@eeeptance tests. 
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i eee Omran ole CYCLE DEVELOPMENT 


This chapter discusses the various phases that theoreti- 
cal software systems vass through during their life cycle 
and the Automated Information System (AIS) life cvcle phases 
described by Department of Defense (DOD) Directive 7920.1. 
The development of the TRIDENT Logistics Data System (LDS) 
is then presented and differences in the way it is being 
developed noted. A background is established in this chapter 
that helps highlight weaknesses in the DOD life cycle phasing 
which could cause budgeting problems. It also assists in 
separating software functions and related costs into the 
Design, Maintenance, and Management budget and cost accumula- 


tion categories addressed in Chapter IV. 


eee eORE tT ITCAL SOFTWARE LIFE CYCLE DEVELOPMENT 

A computer based information system has a life cycle tnat 
is analagous to the life cycle of a living organism. Whether 
it 1s called a life cycle, a development cycle, or an imple- 
mentation cycle, they mean essentially the same thing. [Ref. 
17} A software system begins its life cycle when a need to 
improve information vorocessing procedures is stimulated and 
ends its life cycle with disposal when its existance no longer 
Serves the need or the need is no longer present/has been 
Superceded by a higher priority need. Depending upon the 


degree to which one desires to separate the activities which 
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take place within a software life cycle, there are usually 
from four life cycle phases [Ref. 18] to ten life cycle 
phases [Ref. 19]. In general, a software life cycle can 
be separated into the following phases: (1) Analysis Phase, 
(2) Feasibility Study Phase, (3) Design Phase, (4) Program 
Development and Test Phase, (5) Evaluation Phase, and (6) 
Installation and Operation Phase. While covering the entire 
life cycle of the software system, these ohases concentrate 
On the logical, accurate creation of the system and stress 
BesesoOlLanning. 
1. Analysis Phase 

This phase begins with the need for a new product and 
the acknowledgement of this need by the orgainzation's 
Memagement. Concentration of what the need or problem is 
and not how it is to be solved is made during this phase. 
Ths provosed software user/customer and oroblem environment 
are identified, the role that the proposed product will play 
in satisfying the need is determined, and current capabilities/ 
State of art defined. These asvects are combined into a 
"Requirements Statement" (RS) or vroblem specification describ- 
ing in detail the goals and objectives of the proposed system, 
the capabilities to be included in and excluded from the 
system, performance/processing specifications such as input 
rates, display times, file/record maintenance, output require- 
ments and reports, interface requirements, and timing 


Senstraints. 
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2. Feasibility Study Phase 

The feasibility study phase is sometimes considered 
an extension of the analysis phase, only more technically 
Oriented. Existing procedures are examined in order to 
determine if any existing files, programs, and applications 
can be used or modified to help solve the need and which 
areas Of the proposed system must be designed from scratch. 
Alternate methods of solving the problem are developed and 
each alternative along with the specific problem are studied 
to determine the feasibility of developing it. Feasibility 
is broken down into "operational feasibility" and “economic 
Feasibility". Operational feasibility looks at whether or 
not the product will work performing its specific require- 
ments in an expeditious manner — can input data be collected, 
erros corrected, and the system run on a set schedule? 
Economic feasibility looks at developing the product for a 
reasonable cost and the estimated cost effectiveness of the 
system when in operation [Ref. 20]. Estimates of potential 
costs, time, and effort must be made for developing the 
product as well as projections made for Operating the product. 
Table I lists some project selection criteria that should be 
evaluated during the decision making process [Ref. zl]. The 
selection of a single alternative to pursue leads into the 


next life cycle phase. 
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TABLE I 


SOME POTENTIAL CRITERIA FOR EVALUATING 
ALTERNATIVES IN PROJECT SELECTION 


Tangible and intangible benefits 
User satisfaction 
Percentage of needs met 
Maximum potential of application 
Costs of development 
Costs of operations 
Timing OL COSTS 
Timing of benefits 
Impact On existing operations 
Development time 
Time to implement 
Manpower required 
Analyst 
Programmer 
User 
Probability of success 
Probability of meeting estimates 
New equipment required 


Priomity Of function 


i 





a. Design Phase 


While some preliminary drafting and sketching of 
design ideas is accomplished during the feasibility study 
phase in order to support the decisions made, it is during 
the design phase that the systems analysts get down to design- 
ing a software structure that satisfies the user's require- 
ments detailed in the RS. This is usually accomplished 
through succesSive iterations of the product until it is 
realistic [Ref. 22]. The princival product of the design 
ohase is the Design Specification which describes how the 
planned system will be structured in order to satisfy all 
the requirements of the RS [Ref. 23]. The design specifi- 
cation is the foundation or baseline for all program 
implementations. It includes [Ref. 24]: 

-- a brief narrative and diagrams providing an over- 

view of the entire system 

-- the standards and conventions or rules adopted 

for use in the programs such as flow charting 
Standards; naming standards; interface of com- 
munication standards between program modules, 
components, operations, etc.; and coding standards 
to be used during the programming phase 

-- system file design and layout including sub- 

divisions, files, field length, identifying 


characters, and file relationships and links 
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-- data flow diagrams describing all data trans- 
actions in the system to provide understanding of 
data paths and major events in the operating 
Soe oie 

Table II contains a list of items which should be included in 
the design specification [Ref. 25]. Additionally, during the 
design vhase, the test specifications describing the project 
and the implementation plan detailing all measureable mile- 
stones, aSSignments, resources, and Schedules are produced 
[Ref. 23]. At the end of the design phase the project is 
almost at a point of no return [Ref. 26]. Major amounts of 
resources are about to be committed and the design had better 
be correct. A detailed review of the design specification is 
conducted and, if apvoroved, programming started. 
4. Program Development and Testing Phase 

During this phase the actual work of building the 
software program takes place. The internal design of the 
program is developed, programs are coded, flow charts and 
other system's documentation created and maintained, and 
testing and program debugging accomplished. Unit tests or 
individual tests of low level modules are performed initially 
by the programming teams. As these low level modules are 
made to perform in accordance with the user's requirements, 
they are integrated or strung together to create larger and 
larger portions of the overall project. These integrated 


groups are tested and debugged until the complete system has 
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TABLE II 


DETALLED SxsTEMS DESIGN SPECIFICATIONS 


ie out 


Destination and use 
Medium 
Reports (samples) 


Frequency 


Pau t 


source 
Medium 
Document (sample) 
Fields 


Estimated volume 


Files 


Medium 
Contents 
Record format, field names 


File structure (linkages, 
directories) 


Estimatea file size 


Updating frequency 


Processing 


System flow 

Program specifications 
rou C 
Output 


Errors 
Design decisions 
Modules 
Processing 
Conversion programs 
Heh obhe 
Chis eytlie 
Errors 
Design decisions 
Modules 
Processing 
Manual procedures 
EicOmmecon eiso 
Input error conditions 
Processing errors 
File integrity 
OuEDuUEweBrors 
Backup 
Security 
Work plan 


Program schedule, 
milestones 


Time estimates 


Personnel required 
assignments 





been put together and progressively tested. Figure 8 shows 
the hierarchy of software project testing [Ref. 27]. 
5. Evaluation Phase 

This phase acts as a buffer zone between the inte- 
grated testing verformed by the programmers in the previous 
phase and the start of live use of the product. Its main 
objective is to subject the programmers' products to a 
thorough set of tests neither designed nor executed by them 
and run in an environment that as closely resembles the 
actual environment as possible [Ref. 28]. Test data used 
Should include as many different system's conditions as pos- 
sible and a sample of each type of transaction which will 
occur during operations. Illegal transactions, incorrect 
data entries, improperly coded data, as well as correct data 
transactions should be included in the test data to be sure 
that the programs can operate correctly and have adequate 
error checking and editing features built into them. 
Subsequent to the systems testing, the software product is 
presented to the user for acceptance testing. The acceptance 
test criteria are the conditions that the product must satisfy 
before the user finally accepts the product and agrees that it 
is free of defects and satisfies the specifications of the 
RS [Ref. 29]. Additionally during this phase all the software 
reference documentation is made available to and used to help 
the user on the system. This documentation includes program 


instructions, design documentation, flow charts, user manuals, 
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Operator manuals, maintenance manuals, error list conditions, 
and any other documentation that will make the system easier 
to understand and operate. 
6. Installation and Operation Phase 

For the most part acceptance testing is conducted on 
the user's equipment but for many systems acceptance testing 
is conditional and is followed up by installing the new 
system at the user's operational site and then testing it for 
proper operation. The new software system is generally 
replacing some other type of system — manual, automated, or 
a combination of both — and, therefore, the user's operations 
need to be converted over to the new system after the opera- 
tional site testing has been completed. At this stage, the 
software product generally transitions into the operational 
phase when the system 1S in active and productive use. The 
Operational phase includes activities such as continued 
training, tuning and maintaining the system, and possibly 
system enhancement and lasts until the product is withdrawn 


from active service and disposed of. 


fob ATS LIFE CYCLE PHASES AND SDP MILESTONES 

As with theoretical software systems, DOD has developed 
a life cycle plan for its automated information systems 
through which their development and continued operation is 
Managed. DOD Directive 7920.1 separates the life cycle of 


an AIS into five broad phases: (1) Mission Analysis/Project 
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Initiation, (2) Concept Development, (3) Definition/Design, 
(4) System Development, and (5) Deployment/Operations. It 
also establishes four milestones which help control and 
validate the development of the AIS. Prior to approval to 
proceed from one milestone to the next, specific assigned 
tasks must be completed, policy decisions made, and resource 
requirements (time and cost) confirmed. At each milestone, 
a decision is made to approve continued development of the 
AIS, establish corrective action in order to get the project 
back on track, or discontinue development action. 
1. Mission Analysis/Project Initiation 

This phase of AIS development identifies and validates 
a specific mission need and the deficiencies which prevent the 
successful accomplishment of the mission and presents a recom- 
mendation for analySing various ways by which the mission need 
may be satisfied. The Mission Element Needs Statement (MENS) 
is the method through which this is accomplished. The MENS 
describes a mission need in terms of the job to be done and 
the expected mission results. It describes the mission 
deficiency or non-performance and the impact on the ability 
to accomplish the mission without the new capability. 
Constraints such as operational and logistic limitations; 
interface with existing AIS; timing of need; interservice, 
intraservice, and interoperability requirements; and resource 
limitations are also identified in the MENS. This phase of 


AIS development ends with the aporoval of the MENS and 
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authorizes the analysis and development of alternate methods 
by which to resolve the deficiencies. 

SDP Milestone 0 represents the termination of the 
Mission Analysis/Project Initiation Phase. 

Baeeeconcept Development 

During the second phase of AIS development alternate 
methods of accomplishing the mission need identified in the 
MENS are developed and evaluated. These alternatives are so 
described as to reflect the various state of the art and 
technology bases available to solve the deficiency 
satisfactorily. One or more of these alternatives are desig- 
nated for further evaluation. Modeling and simulation are 
used to establish feasible conceptual baselines for future 
research. Interface between ADP, telecommunications, logis- 
tics, and other elements plus comparison between in-house 
and contractor performance are introduced to the evaluation 
process during this ohase. The significant tasks and 
policies required during the development phase are: 

~- mission need is reaffirmed as necessary 

-- project manager and staff assigned 

-- functional objectives prioritized 

-~ development of detailed functional descriptions 

including inputs, processes, outputs, and 
interfaces 
-- estimated resource requirements are bounded by 


Scranlisnead CONtEraLlnes 
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~~ preliminary project plans are eStablished which 
iiGmIGe™COMnGeDiEs fom training, Operation, logistic 
Support, and organizational relationships 
-- alternatives have considered the use of existing 
hardware and software systems 
-- risk and uncertainty areas are identified and 
included in olanning and evaluation 
-- preliminary test and evaluation plans are 
established 
Demonstration of alternatives or approval to proceed 
directly to the Definition and Design Phase completes this 
phase and is designated as SDP Milestone l. 
3. Definition/Design 
The system/subsystem specifications and functional 
operational requirements are fully defined during this phase 
Of AIS development. Hardware, software, and data base speci- 
fications are developed. A detailed description of the 
functions to be supported by automation is created and speci- 
fic objectives in terms of performance measuring are estab- 
lished and developed during this phase. Feasibility studies 
and economic analvsis are orepared in support of these 
objectives plus training requirements, schedules, and 
projected costs. 
SDP Milestone 2 completes this phase of development 


and represents the approval to fully develonv the AIS. 
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4. Systems Development 

During the fourth phase of the AIS life cycle, the 
total AIS is developed, integrated, tested, and evaluated. 
Computer programs, all data bases, and all system support 
documentation ~— users manuals, maintenance manuals, operators 
manuals — are developed and published. Interrelationships 
and interoperability with other AIS is included in the system 
development. System management and development plans and test 
and acceptance plans are defined during this phase and the 
project held to within the constraints of the resources 
allocated to it. Life cycle schedules and cost estimates are 
Validated realistic, acceptable, and supportive of cost effec- 
tive operations. Hardware and software are field tested using 
actual functional data and certified for satisfying system 
requirements. 

SDP Milestone 3 represents completion of this phase 
and is the approval to deploy and operate the AIS. 

5. Deployment and Operation 

The purpose of this last phase of the AIS life cycle 
is to implement the approved operational plan, ccntinue 
Operations, and budget for continued operations and any 
modifications/changes throughout the useful life of the 
System. Training and resource requirements are to be kept 
current, Operational efficiency and effectiveness periodically 
reevaluated, and major changes approved using the SDP process. 

No SDP Milestone exists for this last phase of AIS 


life cycle management. 
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See tL Ri DENT LDS DEVELOPMENT 

In this section the manner in which the TRIDENT LSD is 
being developed is presented. Additionally, where apparant 
differences exist between the theoretical life cycle phases 
and the DOD life cycle phases, these differences are 
discussed. 

1. Development by Revision 

The TRIDENT LDS has been separated into the basic DOD 

life cycle phases and assigned SDP developmental milestones 
in accordance with the orevailing instructions. As stated in 
Chapter II, the TRIDENT LDS capability also has been separated 
into stages or revisions (see Figure 6). Revision of the 
TRIDENT LDS represents the inital system capability organizing 
the Integrated Logistics Support (ILS) data and supporting 
acquisition of the lead TRIDENT submarine. Revision 0 has 
been completed for all LDS revisions. Revision 1 vrovides 
system capability to support the first TRIDENT submarine refit 
at the TRIREFFAC and incorporates initial TRF/MSS and SMS 
Capabilities, the operational hardware at the TRIREFFAC, and 
a system test bed configuration at the TRIDENT support 
Activities in Mechanicsburg, PA. Revisions 2 and 3 provide 
enhanced system operational capabilities by incorporating 
Mieeral ECCS configuration change control tracking and feed- 
back systems and reorientating the LA/OS module of the LSDS 
branch from an acquisition verspective to an operational 


perspective respectively. Revision 4 completes the LCCS and 
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LSDS branch capabilities and incorporates system hardware 
improvements for the TRIREFFAC and the Systems Command 
Headquarters. These changes complete the multiship, over- 
haul to overhaul, coordinated operating system. Future 
revisions will be provided as necessary to support approved 
changes to the system [Ref. 15]. 

While the DOD instructions governing the development 
of an AIS treat the entire project aS a Single entity, the 
executors and managers of the TRIDENT LDS have chosen to 
break the overall project down into software subprojects 
(revisions) within the total project and to account for each 
revision by its own SDP milestone plan and its own time line. 
This revision phasing has been done in order to facilitate 
management of this vast and complex project and to accommo- 
date progressive upgrades to TRIDENT Submarine System 
operational requirements. 

2. Develooment Timing 
DOD Directive 7920.1 establishes a policy which 
requires: 
"...-AS a goal, the overall AIS will be conceived and 
Sized in a manner that will permit the development and 
evaluation of each module within 9 to 12 months after 
detailed design of the AIS has been completed. ....con- 
mememie tO logic visibility, reliability, maintainability, 
and reduce the risk and cost associated with evaluation 
and validation." 

The TRIDENT LDS is being developed uSing currently approved 


developmental concepts such as top down design, design 


walk-throughs, and chief programmer teams and has integrated 
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existing AIS capabilities but the complexity and uniqueness 
of the project does not support development within the DOD 
time frames. The TRIDENT LDS SDP indicates that the expected 
time required to progress from SDP Milestone 1 to SDP Mile- 
stone 2 — the system Definition/Design Phase — is l year and 
from SDP Milestone 2 to SDP Milestone 3 — the system Develop- 
ment Phase — 2 to 3 years {Ref. 15]. 

It must be noted that these time frames should be 
considered approximations of the time needed to complete these 
phases and are based on the projected size and complexity of 
the programs involved. Therefore, the dates indicated in 
Figure 6 are estimates and schedules to complete the various 
milestone phases should be based on the estimated length of 
time to complete each phase and the actual completion date 
of the preceeding milestone vhase. 

3. Development Documentation 

Figure 9 shows a matrix containing AIS life cycle 
phases, SDP milestones, SDP contents (annexes), and system 
documentation applicable to each SDP milestone [Ref. 30]. 

The breakdown of system documentation by SDP milestones and 
AIS life cycle reflects decisions made by TRIDENT LDS managers. 
It should be noted that this matrix contains some departures 
from the guidelines promulgated by the SECNAV and DOD 
maecructions. 

a. The TRIDENT LDS has adopted a data systems cevelop- 


ment approach which begins with the preparation of a user's RS. 
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mae, TRIDENT LDS considers the RS a product of the Concept 
Development phase and has displaced the preparation of the 
Functional Description (FD) from this phase. Preparation of 
these two documents during the same development phase is 
incompatible although some overlap does occur because system 
designers often assist the users in refining and defining the 
problems to be solved. The RS, as explained in Chapter III A, 
represents the user's problem definition to be solved by the 
AIS and describes in terms of policy, concepts, objectives, 
and scope the requirements of the AIS. The FD builds from 
the RS and describes in detail the requirements of each 
system function identified in the RS including inputs, pro- 
cessing logic, files, and outputs. The FD is based on under- 
standing and Bea between developers, users, and sponsors 
regarding the system's operational capabilities. The FD then 
is a "functional system design" document and acts as a tran- 
Sition vehicle from the RS to preparation of comouter (hard- 
ware and software) design documents. 

The development of an RS, while not specifically 
required by either DOD or Department of the Navy (DON) stand- 
ards, 1S an important aspect of developing an AIS, especially 
eeeomplex one such as the TRIDENT LDS. An RS supports a 
logical progression to creating both system and softward 
Specifications and should be an integral step in the DOD life 
cycle phasing. An FD based on user agreement then is the next 
step to developing good specifications and logically is 


developed after the RS. 
=U) 





DoaiinemcOmreanSiare UuSer requirements accurately 
and completely into both system and software specifications 
during the early stages of project development has been a 
major problem to the success of many software projects [Ref. 
31]. Useful, quality specifications are very difficult and 
time consuming to creat [Ref. 32] and because of the level 
of effort and time constraints placed on the software project, 
there iS a propensity for projects to develop and refine 
requirements as they are developed. These spontaneously 
generated requirements don't always accurately define the 
user's true needs and desires [Ref. 33] and can promote cost 
and schedule overruns. Additionally, poor requirements 
hence poor specifications can induce the following problems 
{[Ref. 34]: 

-- lack of definite guidelines for design personnel 

Bee tmtcwley In producing test plans and procedures 
because no set performance measurements have been 
established 

-- user inputs are minimized because no clear state- 


ment of needs exists 


b. The TRIDENT LDS has shifted the development of 
hardware, software and data base specifications into the 
Development Phase from the Definition/Design Phase. Again, 
this was done to accommodate the logical progression of the 
Project and to facilitate building accurate specifications. 


The SECNAV and DOD instructions do not appear to support the 


=) 





production of a long range, multifaceted, sequentially 
produced AIS and have a tendency of rushing through a system 
SiaeecrOwding the functions together. This could result in 
more errors being produced than would be expected and more 
funds expended. 

Requiring hardware, software, and data base 
specification to be developed when hardware and environmental 
systems have not been determined or developed is very 
difficult. If the hardware and environmental systems to be 
used are presently in production and will be either used as 
1s Or updated, then little or no problems exist for preparing 
these specifications. If, however, the hardware is still in 
a development and testing phase or only has had specifica- 
tions drawn up on it, then the preparation of system 
specifications becomes much more difficult. Such is the 
case with the TRIDENT LDS project. 

c. Developing a multifaceted AIS project creates 
another type of problem regarding scheduling and specifications. 
The TRIDENT LDS has six major functional areas to be developed 
and each of these functional areas has a number of modules or 
application operations (AO) internal to it. An FD is generally 
required for each AO [Ref. 35] but depending upon complexity, 
integration of project capabilities, on line timing require- 
ments, and the like, an FD might only be necessary for each 
branch level within the project or possibly only at the total 


project level. The TRIDENT LDS project has 16 FDs developed/ 
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to be developed and depending upon the revision the AO is in 
the target date for FD preparation and approval can vary by 
several years. The implementation of various AOs and LDS 
branches can and does have significant impacts on the opera- 
tional characteristics of the entire system. Thus, when a 
Peeject 1s faced with this type of situation, it can't wait 
to obtain all the FDs before progressing with software 
development or it may never satisfy the operational deficien- 
Cies addressed in the MENS within specified time constraints. 
Available FDs must be used to obtain projected hardware and 
environmental requirements and broad brush hardware, software, 
and data base specifications developed from these. Under 
these circumstances, it must be realized that specifications 
may require major revisions in the future ag ihe equipment 
is brought closer to on line availability or as additional 
FDs are developed and approved. 
4. Recommendation for Life Cycle Phasing 

Figure 10 presents a possible realignment of AIS life 
cycle phases and SDP Milestones [Ref. 36]. Note that the 
Definition/Design Phase has been divided into two sections 
and an additional SDP milestone review and approval point 
added between the proposed Functional System Design Phase 
and the proposed Computer Design Phase. This allows a 
functional system design to be established, reviewed, and 
decided upon before progressing into the preparation of 


hardware, software, and data base specifications. During 
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this phase the FDs would be prepared and agreed upon and 
initial hardware and environmental requirements established. 
Based on these approved parameters, the next stage of develop- 
ment then would create firm specifications upon which actual 
programming can be started. Additionally the Computer Design 
Phase would allow for the creation of a test bed system for 
in-house test and evaluation prior to on site deployment. 
Prior to progressing into the programming or development 
phase another SDP milestone decision point is encountered for 
additional project review and evaluation. This could be an 
important decision point when dealing with a long range 
innovative AIS. 

The discussion of software life cycle phases and 
development of the TRIDENT LDS has established a foundation 
ileem which to continue into Chapter IV. In the next chapter 
the budget process will be explored and, with the general 
knowledge gained in Chapter III as a basis, the budget 
categories of Design, Maintenance, and Management defined 
and applications of SDP Milestone cost and schedule 


Variances provided. 
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IV. BUDGET GUIDANCE AND CONSTRAINTS 


Life cycle management for Automated Information Systems 
(AIS) is a relatively new concept having been established late 
in 1978 by the Department of Defense (DOD) and applied to 
Department of the Navy (DON) AIS projects by the Secretary of 
the Navy (SECNAV) in late 1979. Little experience has been 
gained regarding AIS life cycle management. As more AIS 
developmental or revision projects are initiated under this 
concept, the more definition is required from it. AIS life 
cycle management 1S currently in a state of evolutionary 
change. 

Chapter III pointed out that the TRIDENT LDS has added to 
the guidelines promulgated by the life cycle instructions and 
has modified the manner and sequencing by which a DOD software 
project is developed. This was done in an attempt to create 
a better base from which to build the system's computer 
programs and to smooth out and facilitate the development of 
this long range project. 

This chapter will continue to delve into DOD's life cycle 
management program and will present a general discussion on 
budget policies, the SDP requirement to categorize TRIDENT 
LDS costs into Design, Maintenance, and Management categories, 
and the impact of the 15 percent cost and schedule variance on 


TRIDENT LDS budget formulation and cost accumulation. 
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PweeeeunpGEl POLICY AND CONTROLS 
PmeNAY Instruction 5231.1A, DOD Directive 7920.1, DOD 
Instruction 7920.2, and the resultant Systems Decision Paper 
SDP) all provide some type of budget guidance to the develop- 
ment of the TRIDENT LDS. While budget guidelines and constraints 
are normal and can be expected in every fiscal situation, care 
must be exercised so that these guidelines are not too confusing, 
too lax, or too restrictive. If any one or a combination of 
these things occur, then the effectiveness and efficiency of 
the organization can be prejudiced. This section presents the 
rational behind budget policies and controls and shows how they 
can affect the operation of an organization. The subsequent 
sections of this chapter will demonstrate what has happened to 
the TRIDENT LDS because of budget policies and controls. 
Budgeting 1S a management process which performs the follow- 
Mee function [Ref. 37]: 
-~ establishes the policy for an organization and sets 
its goals and objectives to attain that policy 
-- identifies weaknesses in an organization and 
provides a method through which they may be corrected 
-- controls and integrates diverse activities carried 
on by numerous subunits of a large organization 
-- provides a means of making an organization, agency, 
government, or individual accountable for its actions 


and through which performance may be judged 
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Appendix C lists some specific advantages and disadvantages 
to performing the budget function [Ref. 33]. 

Budgets are always created within a restricted financial 
environment [Ref. 39] and take strategic plans, policies, 
ideas, and decisions and breaks them down into specific oper- 
ational level resources necessary to accomplish the assigned 
tasks. Every budget decision represents what someone wants to 
do or have someone else do [Ref. 40] and reflects the allocation 
of scarce resources to the alternatives which support the goals 
and objectives of the decision maker. 

Because budgets are usually conceived in a top down fashion 
but prepared and submitted from the bottom up (always in the 
Federal Government), guidance and directions must be given to 
all levels and subunits within the organization on how 1S) Cie, 
about preparing the budget. This is done so that all the 
Subunits will know what programs and activities will be empha- 
Sised or deemphasised during the upcoming budget period, what 
the estimated operating budget levels will be, what budget 
formats to use, when budgets are to be submitted for review and 
approval, who is responsible for preparing the budget submittals, 
what the criteria will be for evaluating the budget submissions, 
and any other general or specific instructions regarding the 
budget. Budget guidance is usually standardized and promulgated 
memorficial Organizational bulletins, circulars, or operating 


procedures. 
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The standard budget guidelines are referenced and supple- 
mented in the "budget call" for the specific budget period 
concerned. This budget call is the device which initiates 
the budget preparation and submittal phase and provides the 
budget guidance to management and operational levels. 

Once the budget has been prepared, approved, and funds 
authorized, a budget execution system must be established. 

The budget exeution system provides directions to organiza- 
tional subunits regarding actual budget operation and est- 
ablishes a review plan by which to measure accomplishment of 
planned objectives [Ref. 41]. Much of the budget execution 
phase centers around budget limitations or budget constraints 
placed upon the obligation and expenditure of available funds. 
Budget limitations may be quite general or very specific and 
take form in the following ways: 
~~ restrict the amount of funds which may be obligated 
or expended over a specified length of time (usually 
the fiscal year or budget year or a portion thereof) 
-- limit the programs, projects, or items on which 
funds may be expended and/or require higher authority 
approval before funds are expended in these areas 
-- restrict the method through which funds may be 
expended - e.g., requiring higher authority approval 
before funds exceeding a certain amount per order 
may be expended or restricting the expenditure of 
funds to certain authorized individuals within the 


organization 
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-- requiring specific types of record keeping, account- 
ing procedures, and reports to be generated and 
forwarded to higher authority for review 

-- setting specific rates of expenditure in order to 
preclude running out of funds before the end of 
the budget period 

-- establishing performance evaluation criteria by 
which the budget execution may be measured 

Budget guidance and budget limitations are instituted with 
One or more of the following managerial ideas in mind: plan- 
mene, COOrdinating, or control [Ref. 43;44]. 

Budget planning involves setting long range and short 
range plans for the entire organization and for each subunit 
within it [Ref. 43]. The organization's long range goals are 
brought down to short range objectives covering the budget 
period and then further subdivided down to the specific 
requirements for each subunit so that they will support 
attainment of the short range objectives and long range goals. 
If done correctly, budget guidance and controls will lead 
management at all levels to actively participate in and 
Sincerely support planning for the organization's future. 

This in turn will tend to promote interest and enthusiasm 
toward the organization and its operations because middle and 
lower level managers will be able to see how their efforts go 
into the operation of the organization and how they can affect 


the overall scheme of things [Ref. 43]. 
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Budget coordination refers to keeping all the organizational 
Subunits working toward a common objective with regards to how 
each subunit affects the other subunits and the accomplishment 
of the stated objectives [{Ref. 42]. For instance, the sales 
and production efforts of an organization have to be closely 
coordinated so that neither one adversely influences each 
other's operations and the objectives of the organization. If 
the sales department over commits the organization's production 
capability, resources may have to be reprogrammed into the 
production department in an attempt to catch up to the demand. 
If the demand can't be satisfied and customer dissatisfaction 
results, the organization's future sales potential may be 
compromised. 

In an ADP development project, resources have to be coor- 
dinated and apportioned between the various modules and phases 
so that they support the timely, accurate development of the 
project. If testing is not resourced adequately, for example, 
the possibility exists that the system will not operate pro- 
perly and will require the outlay of additional funds to 
correct it. Recovery time and cost to correct programming 
defects detected late in the development cycle will be much 
more expensive than the time and funds that would have been 
required to test properly the first time [Ref. 44]. Addition- 
ally, the customer may refuse to accept the project due to 
timing delays, failure to satisfy functional requirements, or 


Significant cost overruns. 
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Coordination starts with a good integrated planning effort 
but relies upon the timely feedback to all managers of informa- 
tion relevant to correct operations and any revisions (additions, 
deletions, or changes) to original plans. 

Finally, budget control concepts and devices stress financial 
accountability. They are geared toward making sure that no 
funds are used for other than approved purposes [Ref. 42]. 
Depending upon the severity of management's perceived need for 
budget control, the control devices employed may be so restric- 
tive and limiting that middle level and low level management 
flexibility is impeded or so lax that fraud and waste is pro- 
moted. If too restrictive, managers spend too much time 
trying to stay within those fiscal and procedural requirements 
that they become unresponsive to emergent demands or changing 
environments. Workers and systems become so engrossed in 
staying within the constraints that their productivity 
decreases [{Ref. 43]. If too lax or too confusing, budget 
controls may permit funds to be expended contrary to manage- 
ment's desires and the organization's goals subverted. 

Managers may also expend considerable amounts of time trying 
to determine exactly what is expected of them and then find- 
ing out that what they have done was not what higher authority 
actually wanted. Funds are wasted when this happens anda 
high degree of dissatisfaction created in the lower management 


eschelons. 
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B. DEFINING DESIGN, MAINTENANCE, AND MANAGEMENT BUDGET 

CATEGORIES 

The Fleet Material Support Office (FMSO 96T) has been 
assigned the responsibility of being the TRIDENT LDS ADP 
Manager. One of the primary tasks assigned to FMSO 96T is 
the definition of and the budget preparation for the resources 
necessary to develop and maintain the TRIDENT LDS software 
project. One of the criteria for budgeting and cost acculu- 
lation which must be followed is the categorization of funds 
and costs into Design, Maintenance, and Management categories. 
These categories have been specified by the TRIDENT Submarine 
ILS Project Manager (NAVSEA PMS 396) by individual Work 
Breakdown Structure (WBS) numbers: 

LDS - Management, B6J33Cl1lA 
LDS - Design, B6J33C1B 
LDS - Maintenance, B6J33C1C 

Funds designated for support of the TRIDENT Submarine 
Development Program are transmitted to FMSO via a Work Request 
(NAVCOMPT Form 140) citing these WBS numbers and the stipula- 
tion that funds cannot be exchanged between WBS numbers with- 
out the approval of the TRIDENT LDS Coordinator at 
Mechanicsburg, PA (SPCC 880). 

Comparing these three WBS task descriptions with the AIS 
life cycle phases discussed in Chapter III, the WBS numbers 
tend to aggregate or consolidate a number of unique functions 
into broader categories and raise the questions of defining 


where design costs start and stop? what constitutes maintenance 
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costs? and what are management costs? in order to budget 
properly for them and avoid cost overruns. 
1. Design 
SECNAV Instruction 5230.6 entitled "Automatic data 

processing approval authority and acquisition/development 
threshold; delegation of" defines AIS development costs — 
and therefore those functions within life cycle phases that 
could be aggregated into the category 'design' — as: 

"... those expenditures which avply to the design, develop- 

ment, test, and implementation of the AIS. When determining 

the overall development cost to be compared to the AIS 

development threshold, sum the development costs from the 

time of approval of the Mission Element Needs Statement 

through the approval authority's acceptance of the system 

as operational (end of the System Development Phase). 

Development costs are one time (in-house and contractual) 

training, functional, personnel, ADP, and telecommunications 

costs. Do not include maintenance costs. a 

While providing a time line for categorizing design 

costs and appearing to define them, this statement does not 
provide a clear enough description to differentiate between 
design and maintenance functions. If the WBS structure 
included a development category instead of a design category 
then possibly this definition could work. However, design 
more accurately describes a portion of the development 
functions and not the overall category. 


Defining design costs (or development costs) as ‘one 
time' costs seems to be overly restrictive. Software 
projects, especially large and complex ones, are usually 


produced over an iterative process of refining and redefining 
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design criteria in order to satisfy the RS. 'One time’ can 
imply that design costs only should consider the first cut at 
developing the software projects but realistically it should 
include all costs up to and including the first time that the 
system satisfies the RS. 

The same type of problem can apply to training costs. 
Should they be associated only with training systems' users 
and hardware/software operators or should such things as 
internal training of systems analysts and programmers assigned 
to the project be included in the costs. 

Time lining design costs from the MENS approval 
through completion of the Development Phase also is question- 
able. Just because the system has gone operational doesn't 
automatically mean that all design functions have been 
completed [Ref. 23]. Operational commitments may have 
required expediting the on line capability before all the 
documentation had been prepared or waiving/postponing certain 
portions of the project. Completion of these items still 
belong under design requirements and should be costed as 
euem (Ref. 23]. 

On the front end of this time line, approval of the 
MENS does not automatically mark the beginning of design/ 
development functions. A very complex project could require 
a Significant amount of effort and time to produce a satis- 
factory problem statement, RS, or FD from which to proceed. 


According to the AIS life cycle phases described in the DOD 
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Misiiructions, this type of effort falls into the Concept 
Development Phase. With the TRIDENT LDS project, FMSO's 
official functions formally start after approval of SDP 
Milestone 1 and continue on throughout the operational phase 
of the project. However, it does provide unscheduled technical 
assistance to the system users and sponsors in developing the 
RS. How then should this work be categorized? If it is 
considered design work, then it is tied to an SDP milestone 
and to a budget governed by a 15 percent variance allowance. 
But how can an accurate work load and budget be projected 
when work is performed on an as requested basis on an as yet 
undefined task? Logically this predesign work should not be 
included in the WBS design category but apportioned to either 
the maintenance category or the management category. 
2. Maintenance 

Approaching the separation of design and maintenance 
from the maintenance aspect also can produce an unsure situa- 
tion. Computer software maintenance is generally associated 
to a system that has been operationally deployed [Ref. 31] 
and is responsible for correcting errors in the released 
product — corrective maintenance — or for providing minor 
alterations on the system — adaptive maintenance. Generally, 
software contractors are contractually obligated to perform 
software maintenance for the user/customer for a specified 


length of time. 
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A distinction is made between the types of product 
improvement because of the impact each has on the product's 
configuration management. Corrective maintenance or repair 
has little or no effect on the system's configuration status 
and is usually generated by detecting that the system does 
not perform the way it is supposed to perform because of 
improper coding, logic, or documentation. Adaptive mainten- 
ance on the other hand requires revision to system specifica- 
tions, coding, and documentation and definitely changes the 
system's configuration account. 

Adaptive maintenance is broken down into two categories — 
revisions and enhancements [Ref. 45]. Software revisions are 
changes to the product made necessary by a change in the 
system's environment, e.g., hardware changes or the addition/ 
deletion of specific required transaction operations. Enhance- 
ments are not considered mandatory changes but merely improve 
the attributes or capabilities of the system. Enhancements 
allow the system to perform more operations thus making it 
attractive to a wider range of users. 

Although commonly done, simply going operational with 
a system does not necessarily mark the end of system design 
development. McHenry and Walston [Ref. 23] warn against 
lumping revisions and enhancements into the maintenance 
category because of the redesign aspect common to both. 
Typically, they claim, software maintenance tasks are given 


to lower skilled persons and that very often when maintenance 
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on the system is requested by the user/customer, a redesign 
criteria is actually introduced by the request. 

Software correction/change proposals are submitted by 
the user one at a time or in small groups. Scheduling the 
implementation of these requests should be determined by the 
criticality and risk involved with the change [Ref. 23]. The 
criticality or importance of a change request is often highly 
subjective and can be judged roughly by the delays and 
aberrations it produces in the system if not implemented 
promptly. By using the ploy of criticality, users can often 
get the software producer to process the change request 
guickly without thoroughly studying its scope. If the pro- 
posed activity alludes to a redesign of the software package 
and not simply minor corrections or minor tuning changes 
[Ref. 45], then this should be renegotiated with the user 
and a new RS obtained. At this point the system should 
reenter the design/development phase. 

The following approach to separating design and 
maintenance has been taken by the TRIDENT LDS [Ref. 46]: 

"Design/Development includes all activity by the (TRIDENT 
LDS ADP Manager) from the approval of a system/application 
RS through initial implementation of the system. (This) 
activity includes the development of original documentation 
and application programs. The acquisition of hardware and 
environmental software necessary to support the new 
requirements is also considered part of the design/ 
development process. Design/development does not include 
revisions to hardware, software and documentation that 

are required to support or modify the interfaces to exist- 
ing systems. An existing system will become a design/ 
development project if required revisions to the system 


are so extensive as to require the generation of a new 
requirements statement ..." 
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"Maintenance includes all activity by the (TRIDENT LDS ADP 
Manager) to enhance and/or modify an operational system. 
This includes the revision of documentation and application 
programs, the expansion/replacement of hardware and environ- 
mental software and facilities modifications, as required, 
to support the continued operation of the system, allow 

for normal growth in capacity and to correct inefficiencies 
and obsolenscence. Maintenance also includes the develop- 
ment and review/resolution of new requirements for future 
design development projects." 

This method of determining whether a function and its 
related cost is in the Design or Maintenance category is 
supported by the information provided in this section. 
Approval of the system's RS provides a specific point at 
which time formal design work can commence and running the 
‘design line’ out until acceptance of the system by the user 
accounts for all the iterations and changes necessary to 
bring that system to an operational status. Once the system 
has been accepted and all supporting documentation provided 
to the user, any work conducted on that system then becomes 
maintenance action. This definition also covers changing the 
scope of the system through maintenance requests. If the 
determination is made that the program changes or maintenance 
action requested by the user have the affect of changing the 
scope of the system, the system then reverts back to a design 
phase and a new RS renegotiated. 

The life cycle management instructions do not assign 
nor call for SDP milestone approval for any functions occur- 


ring after SDP Milestone III (Operations/Development). 


Therefore, maintenance work does not fall under the cost and 
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schedule variance addressed in these directives. With this 
in mind, plus the parameters established by these definitions, 
budget estimates can be more accurately made for those functions 
and costs which are constrained by the budget variance. 

3. Management 

Management functions and management costs can be con- 
sidered analogous to the function/costs of a service depart- 
ment or to overhead charges. A service department renders a 
service which contributes in an indirect manner to producing 
or providing a service but which itself does not directly 
participate in the process. Overhead is generally defined 
as indirect materials, indirect labor, overtime, Supervision, 
fringe benefits or other expenses that can not conveniently 
be identified with or charged directly to a specific final 
cost objective [Ref. 47]. 

Unline direct material and direct labor, service 
departments and overhead are invisible parts of a final cost 
objective. Although they are invisible, these costs are a 
valid portion of the total costs and must be allocated back 
to the end product of the organization. This reallocation 
of costs is usually done on a predetermined rate (e.g., direct 
labor hours, lines of code written, machine hours) and is 
done to distribute these charges as equitably as possible. 

Because of the requirements to report costs by 
Design, Maintenance, and Management categories, the TRIDENT 


LDS has approached the allocation of indirect charges from a 
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Emeramcly Gitrferent aspect. To facilitate cost accumulation 
into these categories, activities and applicable costs have 
been tied to either a line function or a staff function (see 
Figure 11). Line functions are those functions that can be 
tied directly to an LDS branch or Application Operation (AO) 
and include the personnel activities of the following FMSO 
departments: ADP Environmental Software Design (FMSO 94), 
Stock Point Systems Design (FMSO 95), UICP Systems Design 
(FMSO 96), and Financial Systems Design (FMSO 97). Addition- 
ally, while the Management Department (FMSO 92) is a staff 
department it performs work directly attributable to specific 
TRIDENT LDS functions and therefore has been included in the 
line department breakdown. These functions/costs are then 
designated either design or maintenance depending upon what 
LDS branch and AO the personnel are working on and the SDP 
milestone AIS life cycle phase that applies to that specific 
software project. 

If the activity being performed does not originate 
from one of these departments or can be applied to many 
branches, then it is a staff function and classified as 
Management. Those TRIDENT LDS functions/costs which have 
been classified as Management are: TRIDENT LDS ADP Manager 
meee personnel (FMSO 96T), allocation of FMSO Comptroller 
Department (FMSO 91) activities for work performed for the 
TRIDENT LDS project, and allocation of the FMSO Operations 


Analysis Department (FMSO 93) for performance evaluation, 
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modeling, simulation, and measurements taken against all the 
TRIDENT LDS programs written to project system capabilities. 
Additionally, material/supply costs for in-house TRIDENT LDS 
Operations are collected in the Management category plus 
miscellaneous FMSO costs such as tuition, education, printing, 
and equipment rental/services if applicable to work performed 
in support of the TRIDENT LDS. 

TRIDENT has chosen to exclude such costs as overtime, 
labor fringe benefits, and departmental supervisory costs 
trom the Management category. For ease of categorization into 
Design, Maintenance, and Management, these costs are not 
treated as indirect or overhead costs but as direct costs to 
specific LDS functional branches or AOs. Within the budget, 
these costs are segregated out by job order number (e.g., 
LCCS branch management and administration costs and SMS 
branch management and administration costs) but then they 
are aggregated to either Design or Maintenance depending upon 
which stage of development the LDS branch/AO is in. 

The approach to determining Management costs taken 
by the TRIDENT LDS is considered a satisfactory method. It 
facilitates the allocation of labor costs into the various 
categories by setting one criterion for determining whether 
the costs fall into the Design or Maintenance categories or 
into the Management category. If the function being performed 
(and its related costs) can be tied directly to producing a 


specific or a series of specific ADP products, then they are 
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classified as either Design or Maintenance as described 
earlier. All other labor costs then fall out into the 
Management category. If a further breakdown of these 
charges is requested, it can be acquired by selecting the 
appropriate job order number and collecting the costs 
Sm@arged to it. 

Collecting all the miscellaneous costs and material/ 
supply costs into the Management category also makes the 
accumulation of costs easier although slightly less control- 
lable. If these costs were allocated to each TRIDENT LDS 
branch or AO based on their usage then the Design and Mainten- 
ance costs would be more accurate. The cost to do this 
would very likely outweigh the benefit received, however, 
making the accumulation of these costs into the Management 


category more attractive. 


fear MILESTONE COST AND SCHEDULE VARIANCE 

As explained in Chapter III, the DOD and SECNAV instruc- 
tions have established specific decision points during the 
developmental phases of an AIS where the project is reviewed 
and assessed. This is done in order to periodically verify 
that its development continues to fulfill the customer's 
requirements and that it is doing so within projected cost 
and time constraints. These decision points are designated 
as SDP milestones and represent the major controlling steps 


to be attained in developing the AIS. 
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In addition to requiring these SDP milestone decision 
points, DOD and SECNAV have established parameters or con- 
Straints by which to evaluate the AIS project's efficiency in 
resource consumption. Specifically, the life cycle management 
program requires that a corrective action plan be generated, 
reviewed, and approved by the cognizant approval authority 
for the project 1f actual costs and time expended between SDP 
milestones exceeds the planning estimates by 15 percent or 
more. Although this variance constraint sounds relatively 
straightforward, it has been subject to a number of different 
interpretations regarding its meaning. The three most commonly 
occurring interpretations are as follows: 

1. Frozen Budget and Schedule Projections 

This interpretation of the cost and schedule variance 
constraint represents a literal translation of the instruction. 
That is, each milestone phase (Milestone 0 to Milestone l, 
Milestone 1 to Milestone 2, and Milestone 2 to Milestone 3) 
Stands by itself and is allowed up to but not including 15 
percent slippage in either cost or schedule or both before 
notification and a corrective action plan is required. 

Further, once the initial cost and schedule estimates are 

made, they become "frozen" and remain plugged into the mile- 
Stone matrix. These figures are then subject to the 15 percent 
variance allowance. Table III gives a simple example of this 
interpretation and Figure 12 shows the associated cost and 


schedule estimates curve and the variance curve. Note that 


is 
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even 1f a milestone's actual costs and schedule vary from its 
estimated values, the succeeding milestones aren't affected 
and retain their original values. Schedule estimates for 
succeeding milestones simply begin when the previous mile- 
stone has been approved and the project allowed to continue. 
If this interpretation holds true, then an unjustified 15 
percent variance for each milestone would only result in an 
overall unjustified variance for the project of 15 percent. 
This interpretation and functioning of the SDP mile- 
stone varlance constraints might be reasonable if the environ- 
ment within which the AIS is being developed is known and 
stable. If the hardware and environmental systems to be 
used are currently operational (off the shelf procurement) 
and the customer's need (processing deficiency) is accurately 
defined and not an extremely complex task, budget and time 
schedules for the development of the AIS can be estimated 
very accurately. Archibald [Ref. 44] points out that the 
rate of expenditure of resources changes with each phase of 
AIS development, usually increasing with succeeding phases 
with a rapid leveling off or decrease near completion (see 
Figure 13). Developing a processing system from scratch 
using new ideas and new equipment increases the uncertainty 
associated with its creation. Thus, if the initial project 
goal is clear and concise, a more stable cost and schedule 
curve can be expected. A large initial area of uncertainty 


will result in greater awings in the cost and schedule curves 
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as more data is gathered and refined from each succeeding 
phase. This is the type of environment which leads to the 
next two interpretations of the SDP milestone cost and 
schedule variance. 

2. Freezing the Active SDP Milestone Phase 

This interpretation considers only the SDP milestone 
being worked on as being encumbered by the 15 percent cost 
and schedule variance. The active milestone becomes analogous 
to the current fiscal year and performance measurements made 
to evaluate its ability to meet the budget. The outyear 
milestone phases are treated as targets eligible for tuning 
and modifying as more data relative to the project becomes 
available. The outyear milestones become budget constrained 
once the milestone phase has been entered through approval of 
the preceeding milestone. 

Table IV shows an example of what could happen if this 
enterpretation were allowed. The resultant cost and schedule 
estimates curve and its variance curve now appear stepped 
and can permit an actual cost and schedule variance greater 
than 15 percent (see Figure 14). This interpretation allows 
managers a great deal of flexibility regarding the development 
of the project and may result in a more complete and compre- 
hensive capability from the end product. However, it can 
lead to sizable cost overruns and delay on-line availability 
of the system beyond reason. It also makes outyear budgeting 
and matching of anticipated revenues with expenditure require- 


ments very difficult. 
80 





MILESTONE 
PHASE 


ESTIMATES: 


Soot 


TIME 


oie PHASE: 


COST 


eee 


ep) PHASE : 


COST 


TIME 


3RD PHASE 


cOST 


TIME 


PERCENT 
CHANGE: 


B0Rr 7 > 


$100 


2 MO. 


SEs, 


1S) As) ilove 


-~ 


COMPLETED 


Court LED 


CeOMPEE LED 


COMPLETED 


450 


TABLE IV 


SPS 


Le Stites 


Sr 


£5: Mores 


SN ae 


ae) © . 


COME ERE LED 


COMPLETED 


= 1.34 


Stel gS 


FREEZING THE ACTIVE SDP MILESTONE 


$200 


ILS hte 


Sow 


20 Mo.* 


S25 


Zoe Mo 


Soho. 2 


Gy MO: 


oo 


Seoubjyect to change without 15 percent limit 


81 


TOTAL 


$450 


39 Mo. 


3295 


48.8 Mo. 


S02. > 


50'S MOR 


So0 57.0. 


Beco Moz 


= 1.50 





12 





SSeUd SUOFSSTITW ddS SATAOV USeZzZO0IA “PT sanbtg 


G R17 a O,7 ake GE BC Ac ( Zl I 


NS 


SHLNOW NI SINGHHOS d 


y, GL 


AONVINVA LNAQUAd GT ~----- ‘Se OOT 





ATNGHHOS Pub LSOO 





Sc 


OSGi 
sie LSOO 


OO 


GCC 
OS¢ 


oe 


O00 


cc 


OSE 


82 





3. Reprogramming Based on Missed Milestones 


The final interpretation presented combines attributes 
of the preceeding two interpretations. As in the first pre- 
sentation, the cost and schedule estimates are frozen. Ifa 
milestone can not be met within the 15 percent cost and 
schedule variance, the missed milestone must be justified 
and explained in detail and a corrective action plan estab- 
lished which will replan the remainder of the project. Based 
on the corrective action plan, the remaining milestones are 
reprogrammed both in cost and schedule. The milestones that 
are reprogrammed are not subject to the 15 percent variance 
during the reprogramming effort but once that milestone phase 
1s entered, then the 15 percent variance constraint becomes 
binding. Reprogramming does not have to occur only at the 
point when the milestone is ready for review but can occur 
anytime within the milestone phase that it is realized that 
the cost and schedule estimates will not be met and that 
actual requirements will cause the project to exceed its 
variance limits. As in the second interpretation, this inter- 
pretation can result in free adjustments to the budget and 
schedule plans plus the 15 percent cost and schedule variance 
allowed by life cycle management. The estimated cost and 
schedule curve and the variance curve will appear stepped 


Similar to thos presented in Figure 14. 
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Peel ai DENT LDS BUDGET AND SDP INTERFACE 

DOD Instruction 7920.2 requires that an SDP be prepared 
following the approval of the MENS to facilitate and aid the 
decision making process regarding the continued development 
Seetene AIS project. It is the responsibility of the AIS 
project manager to create the SDP and maintain it in an 
updated status throughout the life cycle of the AIS. During 
the developmental phases of the AIS (SDP Milestones 1 through 
3), the project manager is required to update and submit the 
SDP to the Office of the Secretary of Defense (OSD) at each 
succeeding SDP milestone. 

As stated in Chapter III, the TRIDENT LDS project has 
been divided into five revisions over which the entire Broject 
capability will be implemented. Again, this phasing is being 
done to make it easier to manage this project and to coordinate 
project development with increased operational requirements 
of the TRIDENT Submarine System. 

Because of this phased inplementation plan and the varying 
times at which the revisions' SDP milestones are scheduled to 
occur (see Figure 6, the decision was made by the TRIDENT LDS 
managers to update and submit the SDP annually for review and 
approval. The annual review will be supplemented with specific 
approval requests for each TRIDENT LDS revision to pass SDP 
Milestones as required. 

The annual submittal will serve to keep the OSD review 


process current with the TRIDENT LDS status and reduce the 
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number of times that the SDP would need to be submitted for 
a milestone review during a fiscal year. For instance, 
Figure 6 shows that three SDP reviews could occur in fiscal 
year 1981 — Revision 1 Milestone III (August 1981), Revision 2 
Milestone II (September 1981), and Revision 3 Milestone I 
(January 1981). The annual SDP submission will allow a 
detailed look at the entire LDS project (all revisions and 
applicable LDS functional branches) at least once each year. 
The supplemental request will then bring the specific revision 
up to the SDP milestone review point. 
The annual update will additionally be used to tie the 
SDP to the approved TRIDENT LDS budget. The budget is the 
best tool by which to enforce the cost and schedule variances 
allowed by AIS life cycle management. If the SDP is tied to 
the Program Objective Memorandum (POM), the POM is subject 
to more fluctuations and vagaries than is the budget. This 
could result in more mismatches and refiguring for the SDP. 
Finally, an annual update and submittal will allow the 
most current cost and schedule estimates to be included in 
the SDP and actual cost and schedule usage displayed in the 


SDP and matched against the estimates. 
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V. SUMMARY AND CONCLUSIONS 


A. SUMMARY 

Initially, the reader was introduced to the need for 
better management and control of resources identified to the 
develooment of computer software projects. Excessive costs, 
schedule delays, and inability to satisfy customer require- 
ments are common problems experienced with software 
development. 

Implementation of Life Cycle Management for Automated 
Information Systems (AIS) demonstrated Department of Defense 
(DOD) concern for these problems and its attempt to mitigate 
their occurrence. A Be ey document in DOD's Life Cycle 
Management is the Systems Decision Paper (SDP) which contains 
all the essential information on the AIS and is created and 
maintained throughout the life of the AIS. Chapter II 
explains what the TRIDENT Logistics Data System (LDS) is, 
why its develooment is so important to the operations of the 
TRIDENT Submarine fleet, and discusses its transition to life 
cycle management and the SDP process. 

Development of the TRIDENT LDS project was compared to 
the AIS developmental phases identified in the DOD life cycle 
management instructions in Chapter III. It was pointed out 
that the TRIDENT LDS is a long range, complex software system 
that has been divided into five revisions each of which cor- 
respond to increasing operational requirements for the TRIDENT 
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Submarine System. Total TRIDENT LDS system capabilities are 
to be phased in over the successive implementation of these 
revisions. Because of these factors, development of the 
TRIDENT LDS does not fit the mold of the DOD instructions and 
therefore has deviated somewhat from the life cycle phasing 
and software documentation sequences. 

The categorization of TRIDENT LDS costs into Design, 
Maintenance, and Management was discussed in Chapter IV along 
with the 15 percent cost and schedule variances established 
by the life cycle management instructions. Breakdown of 
costs into these three categories and the interpretation of 
the cost and schedule variances tended to be subjective and 
not easily defined. Varying the way in which these guidelines 
are applied could result in very different budget require- 


ments and cost breakdowns. 


ae 6 CONCLUSIONS 

1. Ambiguous definition of customer/user processing needs 
coupled with precipitant development and design of system 
Operating specifications can cause extensive rework of large 
software projects and result in drastic cost overruns and 
schedule delays. Specific definition and concurrence on the 
processing problem should be accomplished prior to performing 
any major software design work and prior to developing hard- 
ware, software, and program specifications, detailed functional 


and operational characteristics should be established. The 
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life cycle management instruction and DOD automated data 
Systems documentation standards tend to compress and overlap 
the sequencing of software documentation preparation and do 
not specify the formulation of a detailed customer's Require- 
ment Statement. This tends to create or foster problems when 
in fact the early planning stages of a software project should 
be based on alleviating problem areas. 

2. The budget and cost accumulation guidelines provided 
by the life cycle management instructions and the SDP are 
subject to numerous interpretations which could cause con- 
Paemen and errors in budgeting and could result in cost 
Overruns. The criteria for placing costs into the categories 
of Design, Maintenance, and Management are satisfactory and 
facilitate cost accumulation. 

Updating the TRIDENT SDP with the annual budget and 
displaying actual cost data against budgeted estimates and 
variance curves will provide a much more timely, useful 
management document. Creating new SDP cost and schedule 
baseline figures each year based on current information will 
present a more accurate status of the project but may run 
contrary to the expectations and policies of the approval 
agencies. 

The author supports the decision to update and submit the 
SDP on an annual basis because this allows the most current 
data to be utilized in the decision making process and pro- 


vides a firm budget figure by which to compare actual expenses. 
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Milestone phases which start and stop within the same fiscal 
year should be constrained by a 15 percent variance for that 
fiscal year. Milestone phases which start in one fiscal year 
but terminate in another fiscal year should not be constrained 
by one 15 percent variance curve for the entire time but 
Should have a 15 percent variance curve for each fiscal year/ 
portion of a fiscal year within which that milestone phase 

is active. Updates of the cost and schedule estimates in 
Support of annual budget submissions should be allowed to 
Migrate to the level supported by current data and not held 
constant to the initial estimates. As a management tool, 
Justification should be provided for any estimate that 
exceeds the estimate provided in the previous year's POM 
process. The 15 percent cost and schedule variance is the 


recommended level at which time justification must be provided. 


C. RECOMMENDATIONS 

l. That AIS life cycle phasing be considered as suggested 
in Figure 10. This includes the definition and approval of a 
Requirements Statement and the addition of an SDP milestone 
review point that will assess development and approval of a 
functional system design prior to the development and approval 
of hardware and software specifications. This will enhance 
the probability of success for the project and reduce expen- 


Sive rework of the project. 
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2. That the 15 percent cost and schedule variance 
described in DOD Directive 7920.1 and SECNAV Instruction 
5231.1A be reviewed and clarification provided regarding 
its meaning and how it is to be applied to AIS budget formu- 
lation and execution. 

3. That consideration be given to requiring the SDP to 
be submitted for review and approval at each major SDP mile- 
stone or at least annually if the time between milestones is 
greater than one year. This would help keep approval auth- 
Ority agencies more current with the progress of the software 
project and permit more timely feedback of actual cost and 


schedule performance. 
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APPENDIX A 


INTEGRATED LOGISTIC SUPPORT (ILS) ELEMENTS 


Maintainability and Reliability of equipment and 
Gomponents. Maintainability is the probability of 
restoring equipment to operating status within allowable 
time limits and reliability is the probability that the 
equipment will continue to function correctly for a 
Specific period of time. 

Maintenance Planning for organizational, intermediate, 

and depot level maintenance action. 

Support and Test Equipment required by the operating 
forces and supporting maintenance activities. 

PMa@oply Support functions 2 menbaclne Provisioning, distri- 
bution and inventory replenishment of repair parts, 
Spares, consumables and any other special supplies. 
MeaamseOrtation and Handling characteristics and require- 
ments necessary to preserve, package, handle and transport 
all equipment and support items. 

Technical Data including drawings; designs; operating 
manuals; maintenance instructions; inspection, test, and 
calibration pvrocedures; and performance specifications. 
Facilities needs based on operation and maintenance require- 
ments including training requirements, test and evaluation 


functions, and installation and maintenance activities. 
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10. 


Personnel and Training requirements for operations and 
maintenance personnel and any training devices needed 
memsupport the program throughout its life cycle. 
Mecasctic Support funding for forecasting life cycle 
costs; planning and apportionment of required capital, 
Operational and research and development costs; and 
allocation of available funds based on justified needs. 
Management information and data for collecting, control- 


meme and managing items 1 through 9. 
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APPENDIX B 


TRIDENT LDS MAJOR BRANCH FUNCTIONS 


MeeesticS Support Data System (LSDS). The LSDS branch is 


composed of TRIDENT unique program modules that support 
data acquiSition, provisioning, support requirements, and 
planned maintenance requirements for the TRIDENT Submarine 
System. Data records will be established for each TRIDENT 
Submarine equipment, component, and system requiring 
maintenance. Engineering and design data will be gathered 
along with all required maintenance actions and the logis- 
tic resources needed to support that maintenance. These 
records will be maintained and updated based on approved 
additions, deletions, and revisions. The LSDS branch has 
numerous TRIDENT unique programs which interface and allow 
data exchange between other standard Navy information 
systems. Maintenance requirements, test equipment, man- 
power skills, spare parts, and other data required to plan 
and schedule refit work at the TRIREFFAC will also be 
available. 

Weapons Support System (WSS). The WSS branch consists of 
standard Navy programs that are currently operational on 
the computers at the logistics centers at Mechanicsburg, 
Pa. When the WSS interfaces with the appropriate TRIDENT 


LDS programs in the LSDS branch, the WSS will generate 
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standard Navy provisioning, Coordinated Shipboard 
Allowance List (COSAL), Incremental Stock Number 

Sequence List (ISNSL), and Load List products all tailored 
to the TRIDENT needs. 

TRIDENT Refit Facility Maintenance Support System (TRF/MSS). 
The TRF/MSS branch contains programs designed to provide 
automated planning, management, and support information 

to facilitate the performance of 18-day TRIDENT refits at 
me@eeTRIREFFAC. The TRF/MSS will collect all planned 
maintenance, deferred maintenance, emergent maintenance, 
and other recurring maintenance requirements into refit 
work packages for the TRIREFFAC. Maintenance listings 

will be generated by Separate work center, task, and 
system/equipment and will indicate all resources necessary 
to complete the required work. The status of each refit 
work package will be fed back into the TRF/MSS program 
beomech atter completion of the refit. This data will 

be used for updating the data files and creating the next 
refit work package for that submarine. Additionally, the 
TRF/MSS branch has program modules that will maintain and 
Gontrol a current inventory of technical data (drawings, 
publications, etc.) needed to support all refit maintenance 
activities; provide an automated tool crib system for the 
mssue, receipt, location, and calibration status of tools 
and test equipment needed for refit work; monitor and 


schedule calibration requirements for tools and test 
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equipment on board each TRIDENT submarine; and finally, 
maintain inventory and maintenance records for TRIREFFAC 
Industrial Plant Equipment. 

Logistics Change Control System (LCCS). LCCS is composed 
of programs which will plan and execute changes and alter- 
ations to equipment/components on board TRIDENT submarines. 
The completion of changes and alterations will be loaded 
back to the data files to ensure that the correct equip- 
ment/component configuration is reflected for proper 
Teqgastic support. 

Supply Management System (SMS). The SMS branch is a 
combination of existing and modified Navy programs and 
TRIDENT unique programs that will provide financial, 
inventory, and other supply functions to TRIDENT sub- 
Marines and the TRIREFFAC. Capabilities will exist to 
monitor, follow up, and report requisition status and 
history; expedite material delivery; prepare and validate 
requisitions; provide automated receipt, storage, and 
issue of material at the TRIREFFAC; establish various 
cross reference files such as Job Order Number (JON) to 
requisition number files and stock number to manufacturers 
part number files; and generate financial reports required 
by the Navy Comptroller (NAVCOMPT) and processing reports 
required by the Fleet Accounting and Disbursing Center 


(FAADC). 
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Environmental Software Systems (ESS). ESS provides the 
operational environment to Support, control, and coordin- 


ate TRIDENT LDS programs operated on TRIDENT LDS hardware. 
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REPEND EX ~C 


ADVANTAGES/DISADVANTAGES OF BUDGETING 


ADVANTAGES 

1. It forces early consideration of basic policies. 

2. It requires adequate and proper organization and 
assignment of responsibility. 

3. It compels all members of management from the top 
down to participate in the establishment of goals. 

4. It forces management to put down in figures what 
is necessary for satisfactory results. 

5. It compels all members of departmental management to 
make plans in harmony with plans of other departments. 

6. It compels management to demand adequate historical 
accounting data. 

7. %&It instills into all levels of management the habit 
of timely, careful, and adequate consideration of 
all factors before reaching important decisions. 

8. It compels management to plan for the most economical 
use of labor, material, facilities, and capital. 

ele Dinpeints efficiency or its lack. 

10. It promotes understanding by management of their co- 
workers' problems. 

ll. It forces a periodic self-analysis of the organization. 


ou, 





eZ. 


ew 


14. 


It checks progress or lack of progress toward the 
objectives. 

It forces management to give timely and adequate 
attention to the effect of the trend in general 
environmental conditions. 

It promotes knowledge at lower levels of basic 


policies and objectives. 


B. DISADVANTAGES 


i 


The budget plan is based on estimates. The estimates 
must be based on all available facts and good judg- 
ment in interpreting and uSing the results. 

Budgetary programs must be continually adapted to fit 
changing circumstances. It can not be installed and 
perfected ina short time. Budget techniques must be 
continually adapted and new techniques tried with 
changing situations. Development may take several 
years and management has to remain patient with it. 
Execution of the budget will not occur automatically. 
Responsible managers must get behind it and contin- 
uously press for its accomplishment. All levels of 
management must be sold on budgeting and participate 
nL a py kt ee 

The budget will not take the place of management and 
administration. It is a tool of management and must 


be used as such. A budget must be treated as a servant 
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and not as a master; it should not be assumed to 


be perfect and impossible to change. 
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